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Description 

SYSTEMS AND METHODS FOR 
MANAGING MULTIPLE ACCOUNTS ON A 
RF TRANSACTION INSTRUMENT 

Cross Reference to Related Applications 

[0001] This application is a continuation in part of, and claims 
priority to, U.S. Patent Application No. 10/608,742, enti- 
tled "METHOD AND APPARATUS FOR ENROLLING WITH 
MULTIPLE TRANSACTION ENVIRONMENTS," filed June 27 
2003, and U.S. Patent Application No. 10/435,420, enti- 
tled "SYSTEM AND METHOD FOR MANAGING ACCOUNT 
INFORMATION LIFE CYCLES," filed May 9, 2003, both of 

which are hereby incorporated by reference. 
Field of Invention 

[0002] The present invention generally relates to payment sys- 
tems, and more particularly, to systems and methods for 
facilitating the management of multiple data sets on vari- 
ous card and "non-card" transaction enabling instru- 



merits. 
Background of Invention 

[0003] Some financial transaction instruments, such as credit 

cards and loyalty program cards, are capable of accessing 
information related to multiple accounts. For example, a 
credit card may be able to access membership data asso- 
ciated with both a credit card account and a wholesale 
purchase club account. These financial transaction instru- 
ments may generally include one or more applications for 
selecting and then securely utilizing a sub-set of specified 
account information. However, the systems associated 
with these cards typically delegate the loading of these 
applications and management of the related data sets to 
third parties on behalf of both the issuer of the instru- 
ment and "application tenants" residing on the issuer's fi- 
nancial transaction instruments. Managing data associated 
with a credit card via the issuer/third party may involve 
time consuming steps such as requesting permission to 
manage data, conforming to data standard formats, and 
implementing changes. Thus, traditional solutions for 
managing multiple application tenants are disadvanta- 
geous in that the traditional solutions leave a dispropor- 
tional burden on the issuer and/or the delegated third 



party in terms of managing accounts on a financial trans- 
action instrument. 
[0004] Another disadvantage is that, in general, the financial 
transaction instruments, which are capable of accessing 
information related to multiple accounts, are typically de- 
signed to access only those multiple accounts managed by 
the same issuer. For example, the same issuer provides 
both the credit card and the wholesale purchase club ac- 
count to the user. As such, the issuer providing both ac- 
counts generally establishes its own application tenant 
storage format and management protocol related to the 
accounts. The established format and protocol is ordinar- 
ily different from any format or protocol used by other 
unrelated issuers, which provides the issuer increased 
control over access to the account data. Because of the 
differing unique protocols/formats amongst issuers, mul- 
tiple issuers typically provide a transaction instrument 
corresponding to an account offered by the issuer, where 
the data for accessing the account is stored in that is- 
suer's protocol/format. Thus, a user wishing to access 
multiple accounts managed by different issuers, must or- 
dinarily carry at least one transaction instrument per is- 
suer. Carrying multiple transaction instruments can be in- 



convenient in that the instruments may be more easily 
misplaced, lost or stolen, preventing the user from ac- 
cessing the account. 
[0005] Another disadvantage of the above conventional methods 
of managing multiple accounts, which is related to the 
different issuer formats/protocols, is that, since conven- 
tional financial transaction instruments typically only store 
application tenant information related to one issuer, the 
information may not be recognized by a second issuer 
distinct from the first. That is, the user of the financial 
transaction instrument typically is only able to use the fi- 
nancial transaction instrument at locations identified by 
the issuer of the transaction card. The financial transac- 
tion instrument may not be used at any other locations, 
since the locations not identified by the user will not rec- 
ognize the application tenant information which is typi- 
cally stored on the instrument in a issuer determined for- 
mat. As such, in order to access multiple accounts man- 
aged by different issuers using different formats/proto- 
cols, the user must typically carry multiple cards, as noted 
above. 

[0006] | n addition to the above, the conventional multiple ac- 
count management systems have another disadvantage in 



that data contained on the financial transaction instru- 
ments may not be easily updated. That is, traditional fi- 
nancial transaction instruments are only "readable" instru- 
ments, and not "writeable" instruments, where the data on 
the instrument may be read from the instrument but not 
written to the instrument. More particularly, once the fi- 
nancial instrument is issued to the user, the data often 
may not be modified. Instead, where information con- 
tained on the instrument is to be modified, a new physical 
consumer device (e.g., transaction instrument) often 
needs to be issued. That is, the information stored on the 
financial transaction instruments are typically not permit- 
ted to be changed without issuer involvement. The issuer 
may be involved, for example, by verifying compatibility 
of a proposed new or updated information, checking con- 
formance of the data to the issuer's standard formatting 
and size guidelines, and implementing the changes. Thus, 
additional burdens are placed on the issuer where it is 
necessary to add unique data sets to a financial transac- 
tion instrument, or to update the data stored thereon. 
[0007] As such, the ability to store data on a single financial 

transaction instrument thereby permitting a user of the 
single instrument to complete transactions using multiple 



transaction accounts issued by different distinct issuers, 
does not exist. A need exists for a single financial trans- 
action instrument which stores multiple independent data 
sets provided by multiple distinct issuers irrespective of 
the format/protocol of the various issuers. A need further 
exists for a single financial transaction instrument which 
may be used to efficiently manage the data sets and ap- 
plications stored on the instrument, irrespective of the 
protocol used by an issuer to process the data. Even more 
particularly, a need exists for a system for managing mul- 
tiple transaction accounts of differing formats on a single 
financial transaction instrument which is issued to a user, 
and which permits the user to access different accounts 

provided by multiple distinct financial account issuers. 
Summary of Invention 

[0008] | n one exemplary embodiment of the present invention, a 
system and method is provided for facilitating the man- 
agement of distinct data sets of different formats on a RF 
operable transaction instrument. The system includes a RF 
financial transaction instrument for use in managing mul- 
tiple distinct data sets provided by distinct issuers. The 
method includes the steps of: receiving, from a read/write 
device, at least a first data of a first format at the financial 



transaction instrument, wherein the first data set is owned 
by a first owner; receiving, from the read/write device, at 
least a second data set of a second format at the financial 
transaction instrument, wherein the second data set is 
owned by a second owner, and wherein the first format is 
different from the second format; storing the first data set 
and the second data set on the financial transaction in- 
strument, in distinct fashion and in accordance with the 
first and second format respectively, where the first data 
set and the second data set are unique one from the 
other; and modifying (e.g., adding, deleting, overwriting, 
altering) at least the first data set, and/or adding a third 
data set, in accordance with instructions provided by the 
data set owner or user. 
[0009] | n another example, a financial transaction instrument 
comprises a data set management system for facilitating 
the management of more than one data set stored on the 
transaction instrument, the RF financial transaction in- 
strument comprising at least one data storage area con- 
figured to store a first data set of a first format and a sec- 
ond data set of a second format different from the first 
format. The first data set is associated with a first data set 
owner (e.g., first issuer) and the first data set is config- 



ured to be stored on the financial transaction instrument 
independent of a second data set owner (e.g., second is- 
suer); and, the second data set is associated with the sec- 
ond owner and the second data set is configured to be 
stored on the financial transaction instrument indepen- 
dent of the first data set owner, wherein the first data set 
and the second data set are stored in accordance with the 
first and second format, respectively. 
[0010] | n y e t another exemplary embodiment of the present in- 
vention, a data management system comprises: a RF fi- 
nancial transaction instrument associated with a first data 
set of a first format and a second data set of a second 
format, wherein the financial transaction instrument is 
configured to facilitate management of the first data set 
without involvement of the first data set owner. The data 
management system may further comprise a read/write 
device configured to communicate with the financial 
transaction instrument for providing the first and second 
data sets to the instrument and for modifying the data 
sets thereon in accordance with a condition header anno- 
tated to the data sets. The read/write device may be stand 
alone, or the device may be connected to a transaction 
processing network. The read/write device may be used to 



load the issuer-owned data onto the transaction instru- 
ment, and thereafter delete, augment and/or manage the 
information stored thereon, or to add additional distinct 
data sets. 

[001 1] As noted, exemplary embodiments of the financial trans- 
action instrument of the present invention may include 
storing a first and second data set of differing formats on 
a transaction instrument database. Alternate exemplary 
embodiments of the present invention may also include a 
"mirror image" of the first and second data set stored on a 
remote database removed from the transaction instrument 
issuer and the transaction instrument itself. The remote 
database may be placed in communication with the trans- 
action instrument issuer system, and the financial trans- 
action instrument via, for example, electronic communi- 
cation with a network. As such, in one exemplary aspect, 
the present invention permits changes which are made on 
the remote database (or transaction instrument) to be 
mimicked or synchronized on the instrument (or remote 
database). 

[° 012 ] In still another exemplary embodiment, the invention se- 
cures authorization from an issuer prior to loading the is- 
suer-owned data onto the RF transaction instrument. 



Once authorization is given, the issuer may be "enrolled" 
in a transaction instrument multiple account management 
system, the associated issuer-owned data may then be 
loaded on the transaction instrument. The issuer-owned 
data may be loaded in a format recognizable by a mer- 
chant system or by a system maintained by issuer. Thus, 
when the transaction instrument is presented to complete 
a transaction, the data may be transferred to the issuer in 
an issuer recognized format, eliminating the need to carry 
multiple transaction instruments for each issuer. That is, 
the issuer receives the data in an issuer recognized format 
and may process the accompanying transaction under is- 
suer's already established business as usual protocols. In 
this way, the issuer is permitted to manage its issuer pro- 
vided program at the issuer location, irrespective of the 
management of other programs provided by other distinct 
issuers enrolled in the multiple account management sys- 
tem. 

Brief Description of Drawings 

[0013] a more complete understanding of the present invention 
may be derived by referring to the detailed description 
and claims when considered in connection with the Fig- 
ures, wherein like reference numbers refer to similar ele- 



merits throughout the Figures, and: 

[0014] FIG. lillustrates a general overview of an exemplary data 
set management method in accordance with an exemplary 
embodiment of the present invention; 

[0015] FIG. 2illustrates a block diagram overview of an exemplary 
data set management system in accordance with an ex- 
emplary embodiment of the present invention; 

[0016] FIG. 3illustrates a more detailed exemplary data set man- 
agement method in accordance with an exemplary em- 
bodiment of the present invention; 

[0017] FIG. 4illustrates an exemplary data set management 

method for adding data sets in accordance with an exem- 
plary embodiment of the present invention; 

[0018] FIG. 5illustrates an exemplary data set management 

method for deleting data sets in accordance with an ex- 
emplary embodiment of the present invention; 

[0019] FIG. 6illustrates an exemplary method for user- 
self-management of data sets in accordance with an ex- 
emplary embodiment of the present invention; 

[0020] FIG. 7illustrates an exemplary method for issuer manage- 
ment of data sets in accordance with the present inven- 
tion; and 

[0021] FIG. 8 illustrates an exemplary data set selection method 



for use in completing a transaction. 
Detailed Description 

[0022] while the exemplary embodiments herein are described in 
sufficient detail to enable those skilled in the art to prac- 
tice the invention, it should be understood that other em- 
bodiments may be realized and that logical and mechani- 
cal changes may be made without departing from the 
spirit and scope of the invention. Thus, the following de- 
tailed description is presented for purposes of illustration 
only and not of limitation. 

[0023] The present invention provides a system and method for a 
RF operable transaction instrument configured to manage 
multiple data sets (e.g., "application tenants") of differing 
formats associated with a plurality of distinct transaction 
account issuers. In this context, an "application tenant" 
may include all or any portion of any data sets which are 
substantially correlated to an account issuer, which the is- 
suer may additionally use to substantially identify an in- 
strument user or related account. For example, where the 
account issuer provides application tenant information, 
the application tenant may include, inter alia, a member- 
ship identifier associated with a user enrolled in a issuer 
provided transaction account program, and all related 



subsets of data stored on the transaction instrument. 
Where multiple application tenants are referred to herein, 
each tenant may constitute its own distinct data set, inde- 
pendent of any other application tenant data sets. For ex- 
ample, each application tenant may include a unique 
membership identifier and all associated subsets of data. 
Alternatively, an application tenant may include a mem- 
bership identifier and an application for processing all 
data owned by an issuer. Thus, the data set or subset may 
include the processing application. Moreover, differing 
formats, as discussed herein, include differences in all or 
any portion of the formats. As such, "application tenant" 
and "distinct data set," and data set "owner" and account 
"issuer" may be used interchangeably herein. 
[0024] | n addition, it should be noted that although the present 
invention is described with respect to a financial transac- 
tion instrument, the invention is not so limited. The in- 
vention is suitable for any instrument capable of storing 
distinct data sets which may be provided by multiple dis- 
tinct account issuers where the distinct data sets may be 
formatted one different from another. The account may 
be, for example, a calling card, a loyalty, debit, credit, in- 
centive, direct debit, savings, financial, membership ac- 



count or the like. While the information provided by the 
account issuers may be described as being "owned" by the 
issuers, the issuers or their designees may simply be a 
manager of the account. 
[0025] The present invention may be described herein in terms of 
functional block components, optional selections and/or 
various processing steps. It should be appreciated that 
such functional blocks may be realized by any number of 
hardware and/or software components configured to per- 
form the specified functions. For example, the present in- 
vention may employ various integrated circuit components 
(e.g., memory elements, processing elements, logic ele- 
ments, look-up tables, and/or the like), which may carry 
out a variety of functions under the control of one or more 
microprocessors or other control devices. Similarly, the 
software elements of the present invention may be imple- 
mented with any programming or scripting language such 
as C, C+ + , Java, COBOL, assembler, PERL, Visual Basic, 
SQL Stored Procedures, extensible markup language 
(XML), with the various algorithms being implemented 
with any combination of data structures, objects, pro- 
cesses, routines or other programming elements. Further, 
it should be noted that the present invention may employ 



any number of conventional techniques for data transmis- 
sion, signaling, data processing, network control, and/or 
the like. For a basic introduction of cryptography and net- 
work security, the following may be helpful references: (1) 
"Applied Cryptography: Protocols, Algorithms, And Source 
Code In C," by Bruce Schneier, published by John Wiley & 
Sons (second edition 1996); (2) "Java Cryptography" by 
Jonathan Knudson, published by O'Reilly & Associates 
(1998); and (3) "Cryptography and Network Security: Prin- 
ciples and Practice" by Mayiam Stalling, published by 
Prentice Hall; all of which are hereby incorporated by ref- 
erence. 

[0026] As used herein, the terms "user," "end user," "consumer," 
"customer" or "participant" may be used interchangeably 
with each other, and each shall mean any person, entity, 
machine, hardware, software and/or business. Further- 
more, the terms "business" or "merchant" may be used in- 
terchangeably with each other and shall mean any person, 
entity, machine, hardware, software or business. Further 
still, the merchant may be any person, entity, software 
and/or hardware that is a provider, broker and/or any 
other entity in the distribution chain of goods or services. 
For example, the merchant may be a ticket/event agency 



(e.g., Ticketmaster, Telecharge, Clear Channel, brokers, 
agents). 

[0027] The systems and/or components of the systems discussed 
herein may also include one or more host servers or other 
computing systems including a processor configured to 
process digital data, a memory coupled to the processor 
for storing digital data, an input digitizer coupled to the 
processor for inputting digital data, an application pro- 
gram stored in the memory and accessible by the proces- 
sor for directing processing of digital data by the proces- 
sor, a display coupled to the processor and memory for 
displaying information derived from digital data processed 
by the processor and a plurality of databases, the 
databases including client data, merchant data, financial 
institution data and/or like data that could be used in as- 
sociation with the present invention. As those skilled in 
the art may appreciate, the user interface for each system 
described herein may typically include an operating sys- 
tem (e.g., Windows NT, 95/98/2000, Linux, Solaris, etc.) 
as well as various conventional support software and 
drivers typically associated with computers. The user 
computer and other systems described herein can be in a 
home or business environment with access to a network. 



In an exemplary embodiment, access is through the Inter- 
net through a commercially-available web-browser soft- 
ware package. 

[0028] Communication between various elements of the present 
invention is accomplished through any suitable communi- 
cation means, such as, for example, a telephone network, 
intranet, Internet, point of interaction device (point of sale 
device, personal digital assistant, cellular phone, kiosk, 
etc.), online communications, off-line communications, 
wireless communications, and/or the like. One skilled in 
the art may also appreciate that, for security reasons, any 
databases, systems, or components of the present inven- 
tion may consist of any combination of databases or com- 
ponents at a single location or at multiple locations, 
wherein each database or system includes any of various 
suitable security features, such as firewalls, access codes, 
encryption, decryption, compression, decompression, 
and/or the like. 

[0029] The systems may be suitably coupled to the network via 
data links. A variety of conventional communications me- 
dia and protocols may be used for data links. For exam- 
ple, a connection to an Internet Service Provider (ISP) over 
the local loop as is typically used in connection with stan- 



dard modem communication, cable modem, Dish net- 
works, ISDN, Digital Subscriber Line (DSL), or various 
wireless communication methods. The merchant system 
might also reside within a local area network (LAN) that 
interfaces to the network via a leased line (Tl, D3, etc.). 
Such communication methods are well known in the art 
and are covered in a variety of standard texts. See, e.g., 
Gilbert Held, "Understanding Data Communications" 
(1996), hereby incorporated by reference. 
[0030] The computing units may be connected with each other 
via a data communication network. The network may be a 
public network and assumed to be insecure and open to 
eavesdroppers. In the illustrated implementation, the net- 
work may be embodied as the Internet. In this context, 
the computers may or may not be connected to the Inter- 
net at all times. For instance, the customer computer may 
employ a modem to occasionally connect to the Internet, 
whereas the bank computing center might maintain a per- 
manent connection to the Internet. Specific information 
related to the protocols, standards, and application soft- 
ware utilized in connection with the Internet may not be 
discussed herein. For further information regarding such 
details, see, for example, Dilip Naik, "Internet Standards 



and Protocols"(1998); "Java 2 Complete," various authors 
(Sybex 1999); Deborah Ray and Eric Ray, "Mastering HTML 
4.0"(1997); Loshin, "TCP/IP Clearly Explained"(1997). All 
of these texts are hereby incorporated by reference. 
[0031] it may be appreciated that many applications of the 

present invention could be formulated. One skilled in the 
art may appreciate that a network may include any system 
for exchanging data or transacting business, such as the 
Internet, an intranet, an extranet, WAN, LAN, satellite 
communications, and/or the like. It is noted that the net- 
work may be implemented as other types of networks, 
such as an interactive television (ITV) network. The users 
may interact with the system via any input device such as 
a keyboard, mouse, kiosk, personal digital assistant, 
handheld computer (e.g., Palm Pilot®), cellular phone and/ 
or the like. Similarly, the invention could be used in con- 
junction with any type of personal computer, network 
computer, workstation, minicomputer, mainframe, or the 
like running any operating system such as any version of 
Windows, Windows NT, Windows2000, Windows 98, Win- 
dows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the 
like. Moreover, although the invention is frequently de- 
scribed herein as being implemented with TCP/IP commu- 



nications protocols, it may be readily understood that the 
invention could also be implemented using IPX, Appletalk, 
IP-6, NetBIOS, OSI or any number of existing or future 
protocols. Moreover, the present invention contemplates 
the use, sale or distribution of any goods, services or in- 
formation over any network having similar functionality 
described herein. 
[0032] | n accordance with various embodiments of the invention, 
the Internet Information Server, Microsoft Transaction 
Server, and Microsoft SQL Server, are used in conjunction 
with the Microsoft operating system, Microsoft NT web 
server software, a Microsoft SQL database system, and a 
Microsoft Commerce Server. Additionally, components 
such as Access or SQL Server, Oracle, Sybase, Informix 
MySQL, Interbase, etc., may be used to provide an ADO- 
compliant database management system. The term "web- 
page" as it is used herein is not meant to limit the type of 
documents and applications that might be used to interact 
with the user. For example, a typical website might in- 
clude, in addition to standard HTML documents, various 
forms, Java applets, Javascript, active server pages (ASP), 
common gateway interface scripts (CGI), extensible 
markup language (XML), dynamic HTML, cascading style 



sheets (CSS), helper applications, plug-ins, and/or the 
like. 

[0033] The financial transaction instrument (e.g., smart card, 

magnetic stripe card, bar code card, optical card, biomet- 
ric device, radio frequency card or transponder and/or the 
like) may communicate to the merchant, information from 
one or more data sets associated with the financial trans- 
action instrument. In one example, membership data and 
credit card data associated with an account or card may 
be transmitted using any conventional protocol for trans- 
mission and/or retrieval of information from an account 
or associated transaction card (e.g., credit, debit, loyalty, 
etc.). In one exemplary embodiment, the transaction in- 
strument may be configured to communicate via RF sig- 
nals. As such, the data contained on the instrument may 
be communicated via radio frequency signals. 

[0034] a financial transaction instrument may include one or 

more physical devices used in carrying out various finan- 
cial transactions. For example, a financial transaction in- 
strument may include a rewards card, charge card, credit 
card, debit card, prepaid card, telephone card, smart card, 
magnetic stripe card, radio frequency card/transponder 
and/or the like. In yet another exemplary embodiment of 



the present invention, a financial transaction instrument 
may be an electronic coupon, voucher, and/or other such 
instrument. 

[0035] The financial transaction instrument in accordance with 
this invention may be used to pay for acquisitions, obtain 
access, provide identification, pay an amount, receive 
payment, redeem reward points and/or the like. In the ra- 
dio frequency ("RF") embodiments of the transaction in- 
strument, instrument to instrument transactions may also 
be performed. See, for example, Sony's "Near Field Com- 
municationT'NFC") emerging standard which is touted as 
operating on 13.56 MHz and allowing the transfer of any 
kind of data between NFC enabled devices and across a 
distance of up to twenty centimeters. See also, Bluetooth 
chaotic network configurations; described in more detail 
at http://www.palowireless.com/infotooth/whatis.asp, 
which is incorporated herein by reference. Furthermore, 
data on a first RF device may be transmitted directly or in- 
directly to another RF device to create a copy of all or part 
of the original device. 

[0036] Furthermore, financial transaction instrument as de- 
scribed herein may be associated with various applications 
which allow the financial transaction instruments to par- 



ticipate in various programs, such as, for example, loyalty 
programs. A loyalty program may include one or more 
loyalty accounts. Exemplary loyalty programs include fre- 
quent flyer miles, on-line points earned from viewing or 
purchasing products or websites on-line and programs 
associated with diner's cards, credit cards, debit cards, 
hotel cards, calling cards, and/or the like. Generally, the 
user is both the owner of the transaction card account and 
the participant in the loyalty program; however, this asso- 
ciation is not necessary. For example, a participant in a 
loyalty program may gift loyalty points to a user who pays 
for a purchase with his own transaction account, but uses 
the gifted loyalty points instead of paying the monetary 
value. 

[0037] For more information on loyalty systems, transaction sys- 
tems, and electronic commerce systems, see, for example, 
U.S. Utility Patent Application Serial No. 10/304,251, filed 
on November 26, 2002, by inventors Antonucci, et al., and 
entitled "System and Method for Transfer of Loyalty 
Points" U.S. Continuation-ln-Part Patent Application Serial 
No. 10/378,456, filed on March 3, 2003, by inventors An- 
tonucci, et al., and entitled "System and Method for the 
Real-Time Transfer of Loyalty Points Between Accounts" 



U.S. Patent Application Serial No. 09/836,213, filed on 
April 17, 2001, by inventors Voltmer, et al., and entitled 
"System And Method For Networked Loyalty Program"; U.S. 
Continuation-ln-Part Patent Application Serial No. 
10/027,984, filed on December 20, 2001, by inventors 
Ariff, et al., and entitled "System And Method For Net- 
worked Loyalty Program"; U.S. Continuation-ln-Part Patent 
Application Serial No. 10/010,947, filed on November 6, 
2001, by inventors Haines, et al., and entitled "System 
And Method For Networked Loyalty Program"; U.S. Contin- 
uation-ln-Part Patent Application Serial No. 10/084,744, 
filed on February 26, 2002, by inventors Bishop, et al., 
and entitled "System And Method For Securing Data 
Through A PDA Portal" the Shop AMEX™ system as dis- 
closed in Serial No. 60/230,190, filed September 5, 2000; 
the Loyalty As Currency™ and Loyalty Rewards Systems 
disclosed in Serial No. 60/197,296, filed on April 14, 
2000, Serial No. 60/200,492, filed April 28, 2000, Serial 
No. 60/201,114, filed May 2, 2000; a digital wallet system 
disclosed in U.S. Serial No. 09/652,899, filed August 31, 
2000; a stored value card as disclosed in Serial No. 
09/241,188, filed on February 1, 1999; a system for facil- 
itating transactions using secondary transaction numbers 



disclosed in Serial No. 09/800,461, filed on March 7, 
2001, and also in related provisional applications Serial 
No. 60/187,620, filed March 7, 2000, Serial No. 
60/200,625, filed April 28, 2000, and Serial No. 
60/213,323, filed May 22, 2000, all of which are herein 
incorporated by reference. Other examples of online loy- 
alty systems are disclosed in Netcentives U.S. Patent No. 
5,774,870, issued on June 30, 1998, and U.S. Patent No. 
6,009,412, issued on December 29, 1999, both of which 
are hereby incorporated by reference. 
[0038] Further still, a "code," "account," "account number," "iden- 
tifier," "loyalty number" or "membership identifier," as 
used herein, includes any device, code, or other identifier/ 
indicia suitably configured to allow the consumer to inter- 
act or communicate with the system, such as, for exam- 
ple, authorization/access code, personal identification 
number (PIN), Internet code, other identification code, 
and/or the like that is optionally located on a rewards 
card, charge card, credit card, debit card, prepaid card, 
telephone card, smart card, magnetic stripe card, bar code 
card, radio frequency card and/or the like. The account 
number may be distributed and stored in any form of 
plastic, electronic, magnetic, radio frequency, audio and/ 



or optical device capable of transmitting or downloading 
data from itself to a second device. A customer account 
number may be, for example, a sixteen-digit credit card 
number, although each credit provider has its own num- 
bering system, such as the fifteen-digit numbering sys- 
tem used by an exemplary loyalty system. Each company's 
credit card numbers comply with that company's stan- 
dardized format such that the company using a sixteen- 
digit format may generally use four spaced sets of num- 
bers, as represented by the number "0000 0000 0000 
0000." The first five to seven digits are reserved for pro- 
cessing purposes and identify the issuing bank, card type 
and etc. In this example, the last sixteenth digit is used as 
a sum check for the sixteen-digit number. The intermedi- 
ary eight-to-ten digits are used to uniquely identify the 
customer. In addition, loyalty account numbers of various 
types may be used. 
[0039] Further yet, the "transaction information" in accordance 
with this invention may include the nature or amount of 
transaction, as well as, a merchant, user, and/or issuer 
identifier, security codes, or routing numbers, and the 
like. In various exemplary embodiments of the present in- 
vention, one or more transaction accounts may be used to 



satisfy or complete a transaction. For example, the trans- 
action may be only partially completed using the transac- 
tion account(s) correlating to the application tenant infor- 
mation stored on the transaction instrument with the bal- 
ance of the transaction being completed using other 
sources. Cash may be used to complete part of a transac- 
tion and the transaction account associated with a user 
and the transaction instrument, may be used to satisfy the 
balance of the transaction. Alternatively, the user may 
identify which transaction account, or combination of 
transaction accounts, stored on the transaction instru- 
ment the user desires to complete the transaction. Any 
known or new methods and/or systems configured to ma- 
nipulate the transaction account in accordance with the 
invention may be used. 
[0040] | n various exemplary embodiments, the financial transac- 
tion instrument may be embodied in form factors other 
than, for example, a card-like structure. As already men- 
tioned, the financial transaction instrument may comprise 
an RF transponder, a speed pass, store discount card, or 
other similar device. Furthermore, the financial transac- 
tion instrument may be physically configured to have any 
decorative or fanciful shape including key chains, jewelry 



and/or the like. The financial transaction instrument may 
furthermore be associated with coupons. A typical RF de- 
vice which may be used by the present invention is dis- 
closed in U.S. Application Serial No. 10/192,488, entitled 
"System And Method For Payment Using Radio Frequency 
Identification In Contact And Contactless Transactions," 
and its progeny, which are all commonly assigned, and 
which are all incorporated herein by reference. 
[0041] As used herein, the term "data set" may include any set of 
information and/or the like which may be used, for exam- 
ple, in completing a transaction. For example, data sets 
may include information related to credit cards, debit 
cards, membership clubs, loyalty programs, speed pass 
accounts, rental car memberships, frequent flyer pro- 
grams, coupons, tickets and/or the like. This information 
may include membership identifiers, account number(s), 
personal information, balances, past transaction details, 
account issuer routing number, cookies, identifiers, secu- 
rity codes, and/or any other information. The data set 
may additionally include an issuer defined management 
process for determining which subsets of data are to be 
provided to an issuer or merchant. In some instances, a 
data set may be associated with one or more account 



numbers corresponding to accounts maintained by the 
account issuer. 

[0042] The various data sets associated with a financial transac- 
tion instrument may either be stored on the financial 
transaction instrument itself or remotely. In one exem- 
plary embodiment, the financial transaction instrument it- 
self is configured to store at least two data sets. In other 
exemplary embodiments, data sets may be stored in one 
or more databases and the data sets are affiliated with the 
financial transaction instrument. For example, a central 
database on the instrument may store multiple distinct 
data sets correlated with a unique issuer. The data sets 
stored on the remote database may be stored thereon, in 
such a manner as to mimic the corresponding data sets 
stored on the transaction instrument. The multiple distinct 
data sets may be accessed, for example, by a merchant 
system, whether stored on the transaction instrument or 
remote database stand alone device, and/or a computer 
user interface, via a network. In this example, the financial 
transaction instrument may include one or more user 
identifiers (e.g., membership identifiers), which may be 
used to provide access to a subset of data included on the 
financial transaction instrument. 



[0043] Various information and data are described herein as be- 
ing "stored." In this context, "stored" may mean that the 
information is kept on a database. In accordance with the 
invention, a database may be any type of database, such 
as relational, hierarchical, object-oriented, and/or the 
like. Common database products that may be used to im- 
plement the databases include DB2 by IBM (White Plains, 
New York), any of the database products available from 
Oracle Corporation (Redwood Shores, California), Mi- 
crosoft Access or MSSQL by Microsoft Corporation 
(Redmond, Washington), or any other database product. A 
database may be organized in any suitable manner, in- 
cluding as data tables or lookup tables. Association of 
certain data may be accomplished through any data asso- 
ciation technique known and/or practiced in the art. For 
example, the association may be accomplished either 
manually or automatically. Automatic association tech- 
niques may include, for example, a database search, a 
database merge, GREP, AGREP, SQL, and/or the like. The 
association step may be accomplished by a database 
merge function, for example, using a "key field" in each of 
the manufacturer and retailer data tables. A "key field" 
partitions the database according to the high-level class 



of objects defined by the key field. For example, a certain 
class may be designated as a key field in both the first 
data table and the second data table, and the two data ta- 
bles may then be merged on the basis of the class data in 
the key field. In this embodiment, the data corresponding 
to the key field in each of the merged data tables is 
preferably the same. However, data tables having similar, 
though not identical, data in the key fields may also be 
merged by using AGREP, for example. 
[0044] Although all data sets associated with a particular finan- 
cial transaction instrument may be owned by the same 
owner, it is contemplated that in general, some of the 
data sets stored on the financial transaction instrument 
have different owners. Furthermore, the storage of data 
sets is configured to facilitate independent storage and 
management of the data sets on the financial transaction 
instrument. Further still, the data sets may be stored in 
distinct differing formats provided by the distinct issuer or 
data set owner (also called "issuer," herein). The owners of 
data sets may include different individuals, entities, busi- 
nesses, corporations, software, hardware, and/or the like. 
However, one skilled in the art will appreciate that the 
owners may also include different divisions or affiliates of 



the same corporation or entity. 

[0045] a data set may contain any type of information stored in 
digital format. For example, a data set may include ac- 
count numbers, programs/applications, scripts, cookies, 
instruments for accessing other data sets, and/or any 
other information. 

[0046] As discussed above, many issuers of existing financial 

transaction instruments utilize predetermined formats for 
account numbers, data and/or applications stored in as- 
sociation with the financial transaction instrument. Simi- 
larly, the data storage media associated with these finan- 
cial transaction instruments are typically configured to ac- 
commodate specific predetermined data formats. Thus, 
since the data format associated with a first issuer is often 
different from a data format of a second issuer, storage of 
multiple distinct data of differing formats on a single de- 
vice provides complications for conventional systems. This 
is true since, each issuer typically maintains an account 
processing system that uses a processing protocol differ- 
ent from other issuers, and the information stored on the 
transaction card relative to the issuer must be formatted 
accordingly. As such, to ensure the security and integrity 
of the issuer-owned data, the loading of data on a trans- 



action instrument is typically performed by an issuer or a 
third-party provider who typically uploads all related and 
similarly formatted data sets onto the transaction instru- 
ment. However, since the third party may typically only be 
authorized by the issuer to load issuer-owned data of 
similar format onto an issuer-provided transaction device, 
including differently formatted data sets on a single 
transaction device by the third party is often not permit- 
ted. More particularly, independent owners of data sets 
are often reluctant to conform their data set formats to a 
"standard format" because of the security advantages of 
maintaining a separate, distinct, often secreted format. 
[0047] | n contrast, and in accordance with an exemplary embodi- 
ment of the present invention, the format of the informa- 
tion stored in the present invention may vary from one 
data set to another. That is, the present invention permits 
the data to be stored on the financial transaction instru- 
ment in any format, and more particularly, in any format 
recognizable by the data owner/transaction instrument 
issuer. Thus, as noted, each data set may be used for a 
very wide variety of purposes including storage of appli- 
cations, raw data, cookies, coupons, membership data, 
account balances, loyalty information, and/or the like. 



[0048] | n accordance with one aspect of the present invention, 
any suitable data storage technique may be utilized to 
store data without a standard format. Data sets may be 
stored using any suitable technique, including, for exam- 
ple, storing individual files using an ISO/IEC 7816-4 file 
structure; implementing a domain whereby a dedicated 
file is selected that exposes one or more elementary files 
containing one or more data sets; using data sets stored 
in individual files using a hierarchical filing system; data 
sets stored as records in a single file (including compres- 
sion, SQL accessible, hashed via one or more keys, nu- 
meric, alphabetical by first tuple, etc.); block of binary 
(BLOB); stored as ungrouped data elements encoded using 
ISO/IEC 7816-6 data elements; stored as ungrouped data 
elements encoded using ISO/IEC Abstract Syntax Notation 
(ASN.l) as in ISO/IEC 8824 and 8825; and/or other pro- 
prietary techniques that may include fractal compression 
methods, image compression methods, etc. 

[0049] | n 0 ne exemplary embodiment, the ability to store a wide 
variety of information in different formats is facilitated by 
storing the information as a Block of Binary (BLOB). Thus, 
any binary information can be stored in a storage space 
associated with a data set. As discussed above, the binary 



information may be stored on the financial transaction in- 
strument or external to but affiliated with the financial 
transaction instrument. The BLOB method may store data 
sets as ungrouped data elements formatted as a block of 
binary via a fixed memory offset using either fixed stor- 
age allocation, circular queue techniques, or best prac- 
tices with respect to memory management (e.g., paged 
memory, memory recently used, etc.). By using BLOB 
methods, the ability to store various data sets that have 
different formats facilitates the storage of data associated 
with the financial transaction instrument by multiple and 
unrelated owners of the data sets. For example, a first 
data set which may be stored may be provided by a first 
issuer, a second data set which may be stored may be 
provided by an unrelated second issuer, and yet a third 
data set which may be stored, may be provided by a third 
issuer unrelated to the first and second issuers. Each of 
these three exemplary data sets may contain different in- 
formation that is stored using different data storage for- 
mats and/or techniques. Further, each data set may con- 
tain subsets of data which also may be distinct from other 
subsets. 

[0050] Even further, where the invention contemplates the use of 



a self-service user interaction device. In this context, the 
self-service user interaction device may be any device 
suitable for interacting with a transaction instrument, and 
receiving information from the transaction instrument 
user and providing the information to a merchant, account 
issuer, account manager, data set owner, merchant point 
of sale, and the like. For example, the self-service user 
interaction device may be a stand alone read write device, 
self-service Kiosk, merchant point of sale, read/write de- 
vice, and the like. In one example, the self-service user 
interaction device may be configured to communicate in- 
formation to and from the transaction device and to ma- 
nipulate the data sets stored thereon. The self-service in- 
teraction device may be in communication with the vari- 
ous components of the invention using any communica- 
tions protocol. 

[0051] | n general, systems and methods disclosed herein, are 
configured to facilitate the management of multiple dis- 
tinct data sets associated with a financial transaction in- 
strument. Management of data sets may include such 
steps as adding, augmenting, updating and/or deleting 
data sets associated with the financial transaction instru- 
ment. Such manipulations of the data may occur without 



replacing or reissuing the financial transaction instrument. 
With reference to FIG. 1, an exemplary method 100 ac- 
cording to the present invention is shown. Method 100 
may include issuing a financial transaction instrument is- 
sued to a transaction device user (step 110), enrolling 
multiple data set owners in a multiple account on a trans- 
action device program (step 112), and managing data sets 
associated with the financial transaction instrument (step 
120). In managing the data, the method 100 may deter- 
mine, for example, whether the data should be added to a 
data set (step 130), modified (step 140) or deleted (step 
150), as described more fully below. Once the data is ap- 
propriately managed, the financial transaction instrument 
user may present the data contained on the instrument to 
a merchant system for completion of a transaction. 
[0052] The system may be further configured such that, during 

an exemplary transaction, data sets associated with the fi- 
nancial transaction instrument may be managed. For ex- 
ample, the user may be prompted (e.g., on a screen, by 
electronic voice, by a store clerk, by a signal and/or the 
like) as to the possibility of adding, for example, a loyalty 
account to the same financial transaction instrument and 
the user may also be presented with terms and/or condi- 



tions in a similar or different manner. The user may be 
prompted at any time during the transaction, but prefer- 
ably the user is prompted at the completion of the trans- 
action. If the user accepts the invitation to add data to the 
financial transaction instrument, a new data set may be 
added (step 130) and/or an existing data set is updated 
(step 140). For example, if data is to be updated, the 
stand alone may locate appropriate data to be updated on 
the transaction device, and make the updates 
("modifications") in accordance with data owner instruc- 
tions. If the data is to be added, the stand alone device 
may be configured to provide any account information 
(e.g., account identifier, security code, data owner routing 
number, etc.) to the transaction device for storage 
thereon. The stand alone may locate an appropriate 
database location on transaction instrument for storing 
the added data. The stand alone device facilitates storage 
of the data in a distinct location on the transaction device 
database, where the data is stored independently of any 
other data. In a preferred embodiment of the invention, 
the data is added to a database location on the transac- 
tion device which reserved for independently storing all 
data owned by a particular data set owner. Alternatively, 



the data may be stored in a distinct location on the trans- 
action device, which is a separate location than is used to 
store any other data set. Further still, the data set is 
stored in accordance with any storage protocol permitting 
the data to be stored and retrieved independently of other 
data. 

[0053] The adding and updating of the data may be verified by 
the issuer, prior to making the modifications. If verified, 
all databases containing the data set to be updated or a 
mirror image of the data set to be updated, are modified 
in accordance with the user or issuer provided instruc- 
tions, and/or the issuer defined data storage protocol or 
format. 

[0054] | n one exemplary embodiment, multiple account issuers 
may be enrolled in a multiple account management pro- 
gram using a financial transaction instrument in accor- 
dance with the invention (step 112). For example, permis- 
sion for adding account issuer owned data may be ob- 
tained from the data set owner. The data set owner may 
then be requested to provide account information to be 
stored on a transaction instrument. The data set owner 
may then provide account information relative to a distinct 
user account for loading onto the transaction instrument 



in accordance with the present invention. The issuers may 
be enrolled prior to issuance of the instrument or the is- 
suers may be enrolled after issuance. By enrolling in the 
management program, the issuer may provide authoriza- 
tion for including the issuer-owned data on the financial 
transaction instrument. The issuer-owned data may be in- 
cluded (e.g., added, deleted, modified, augmented, etc.) 
on the transaction instrument using a stand alone interac- 
tion device, merchant system, or user personal computer 
interface upon presentment of the transaction device to 
the stand alone interaction device 290 (step 114). The 
stand alone interaction device may manipulate the issuer- 
owned data while preserving a format recognizable by an 
issuer account management system. For example, the 
stand alone device may identify the appropriate header or 
trailer associated with the data and add, delete or modify 
the data accordingly. The stand alone may manipulate the 
data using any manipulation instruction or protocol as 
provided by the data set owner so that the resulting ma- 
nipulated data is in a format recognizable by the data set 
owner system. In this way, the stand alone device may 
manipulate the data while maintaining the data set 
owner's format. Alternatively, the interaction device may 



store the issuer-owned data on the transaction instrument 
in any format, provided that the issuer-owned data is 
provided to the issuer system (or to merchant system) in 
an issuer system (or merchant system) recognizable for- 
mat. 

[0055] it should be noted, that the financial transaction instru- 
ment may be issued with or without one or more data sets 
stored thereon. The financial transaction instrument may 
be issued using various techniques and practices now 
known or hereinafter developed wherein an instrument is 
prepared (e.g., embossed and/or loaded with data) and 
made available to a user for effecting transactions. Al- 
though the present invention may contemplate managing 
data sets (step 120) before issuing a financial transaction 
instrument (step 110), in various exemplary embodi- 
ments, by way of illustration, the data sets are described 
herein as being managed (step 120) after issuance (step 
110). 

[0056] At any time after issuance (step 110) of the financial 

transaction instrument, the financial transaction instru- 
ment may be used in a commercial transaction. In one ex- 
emplary embodiment of the present invention, a user 
communicates with a merchant, indicates a desire to par- 



ticipate in an issuer provided consumer program. The user 
may communicate with the merchant by, for example, 
presenting the transaction instrument to the merchant 
and indicting a desire to complete a transaction. The user 
may indicate his desire to complete a transaction using 
any conventional process used by the merchant. The user 
may further indicate that the user wished to complete the 
transaction using the financial transaction instrument. 

[0057] During completion of the transaction, the user may 

present the financial transaction instrument to a merchant 
system. The financial transaction instrument is configured 
to communicate with the merchant, using any conven- 
tional method for facilitating a transaction over a network. 

[0058] As stated above, in various embodiments of the present 
invention, the data can be stored without regard to a 
common format. However, in one exemplary embodiment 
of the present invention, the data set (e.g., BLOB) may be 
annotated in a standard manner when provided for ma- 
nipulating the data onto the financial transaction instru- 
ment. The annotation may comprise a short header, 
trailer, or other appropriate indicator related to each data 
set that is configured to convey information useful in 
managing the various data sets. For example, the annota- 



tion may be called a "condition header," "header," "trailer," 
or "status," herein, and may comprise an indication of the 
status of the data set or may include an identifier corre- 
lated to a specific issuer or owner of the data. In one ex- 
ample, the first three bytes of each data set BLOB may be 
configured or configurable to indicate the status of that 
particular data set (e.g., LOADED, INITIALIZED, READY, 
BLOCKED, REMOVABLE, or DELETED). Subsequent bytes of 
data may be used to indicate for example, the identity of 
the issuer, user, transaction/membership account identi- 
fier or the like. Each of these condition annotations are 
further discussed herein. 
[0059] The data set annotation may also be used for other types 
of status information as well as various other purposes. 
For example, the data set annotation may include security 
information establishing access levels. The access levels 
may, for example, be configured to permit only certain in- 
dividuals, levels of employees, companies, or other enti- 
ties to access data sets, or to permit access to specific 
data sets based on the transaction, merchant, issuer, user 
or the like. Furthermore, the security information may re- 
strict/permit only certain actions such as accessing, mod- 
ifying, and/or deleting data sets. In one example, the data 



set annotation indicates that only the data set owner or 
the user are permitted to delete a data set, various identi- 
fied merchants are permitted to access the data set for 
reading, and others are altogether excluded from access- 
ing the data set. However, other access restriction param- 
eters may also be used allowing various entities to access 
a data set with various permission levels as appropriate. 
[0060] The data, including the header or trailer may be received 
from a data set owner via any communication method de- 
scribed herein. The header or trailer may be appended to 
a data set to be modified, added or deleted, to indicate 
the action to be taken relative to the data set. The data set 
owner may provide the to a stand alone interaction device 
configured to add, delete, modify, or augment the data in 
accordance with the header or trailer. As such, in one ex- 
emplary embodiment, the header or trailer is not stored 
on the transaction device along with the associated is- 
suer-owned data but instead the appropriate action may 
be taken by providing to the transaction instrument user 
at the stand alone device, the appropriate option for the 
action to be taken. However, the present invention con- 
templates a data storage arrangement wherein the header 
or trailer, or header or trailer history, of the data is stored 



on the transaction instrument in relation to the appropri- 
ate data. 

[0061] | n various exemplary embodiments, the steps of adding, 
deleting, augmenting and/or modifying data sets may be 
repeated. For example, first, second, and additional data 
sets may be added (step 130) to the financial transaction 
instrument in any order. In one exemplary embodiment of 
the present invention, the first data set is owned by a first 
data set owner (i.e., first issuer) and the second data set is 
owned by a second data set owner (i.e., second issuer). 
Furthermore, the system may include replacing a first data 
set with a subsequent data set by deleting a data set (step 
150), then adding a data set (step 130). 

[0062] with reference now to FIG. 2, in one exemplary embodi- 
ment of the present invention, a data set management 
system ("management system") 200 comprises a merchant 
system 220, various issuer systems 230, and a financial 
transaction instrument 240. Management system 200 may 
further be accessed by a user 201 on a self-service inter- 
action device, such as, for example, user computer 250 or 
via a transaction device such as, for example, kiosk 270, 
stand alone interaction device 290, automated teller, or 
the like. In these examples, communications between user 



computer 250 or kiosk 270 and merchant system 220 or 
issuer systems 230 may take place via, for example, a 
network 260. In various embodiments, merchant system 
220, user computer 250 and/or kiosk 270 are configured 
to communicate with financial transaction instrument 240. 
For example, communication with the financial transaction 
instrument 240 may be facilitated by a point of read/write 
device 280, such as a merchant point of sale, merchant 
RFID reader, computer interface, or the like, configured to 
receive information provided by the financial transaction 
instrument 240. 

[0063] | n general, merchant system 220 is configured to interact 
with a user 201 attempting to complete a transaction, and 
to communicate transaction data to one or more of issuer 
systems 230. Issuer systems 230 are configured to inter- 
act with financial transaction instrument 240 to receive 
and/or exchange data facilitating a transaction. Merchant 
system 220 may be operated, controlled and/or facilitated 
by any merchant that accepts payment via a transaction 
instrument. 

[0064] Merchant system 220 is configured to facilitate interaction 
with user 201, which may be any person, entity, software 
and/or hardware. The user 201 may communicate with 



the merchant in person (e.g., at the box office), or elec- 
tronically (e.g., from a user computer 250 via network 
260). During the interaction, the merchant may offer 
goods and/or services to the user 201. The merchant may 
also offer the user 201 the option of completing the 
transaction using a financial transaction instrument. The 
merchant system may provide the options to the user 201 
using interactive user interface, suitable website or other 
Internet-based graphical user interface that is accessible 
by users. 

[0065] Each user 201 may be equipped with a computing system 
to facilitate online commerce transactions. For example, 
the user 201 may have a computing unit in the form of a 
personal computer (e.g., user computer 250), although 
other types of computing units may be used including 
laptops, notebooks, hand held computers, set-top boxes, 
and/or the like. The merchant system 220 may have a 
computing unit 222 implemented in the form of a com- 
puter-server, although other implementations are possi- 
ble. The issuer system 230 may have a computing center 
such as a main frame computer. However, the issuer com- 
puting center may be implemented in other forms, such 
as a mini-computer, a PC server, a network set of com- 



puters, or the like. 

[0066] issuer system 230 may be configured to manipulate a 

transaction account associated with the corresponding is- 
suer-owned data stored on the transaction instrument 
240 (or database 282, discussed below) in accordance 
with a related transaction. For example, the issuer system 
230 may receive "transaction information" and manipulate 
an account status or balance in accordance with the infor- 
mation received. In accordance with the transaction 
amount, the issuer system 230 may, for example, dimin- 
ish a value available for completing a transaction associ- 
ated with the account, or the issuer system 230 may alter 
the information relative to the account user (e.g., demo- 
graphics, personal information, etc.). 

[0067] | t should be noted that issuer systems 230 may also be 
configured to interact with financial transaction instru- 
ment 240, directly or indirectly via database 282 or stand 
alone interaction device 290, to individually manage data 
sets on financial transaction instrument 240. For example, 
issuer systems 230 may manage data sets on database 
282. In some embodiments, the data sets on database 
282 may then be stored on financial transaction instru- 
ment 240 when the transaction instrument is presented. 



In other embodiments, issuer systems 230 may store data 
set information within their own systems which may com- 
municate with the financial transaction instrument via 
user computer 250, kiosk 270, or merchant system 220. 
In such embodiments, the issuer system 230 may be con- 
figured to push the data set to the financial transaction 
instrument 240 via the stand alone interaction device 290, 
or the merchant system 220, kiosk 270, interaction device 
290 or computer 250 which may be configured to pull 
such information from the issuer system 230. 

[0068] | n addition, the data may be manipulated using, for ex- 
ample, a stand alone interaction device 290 configured to 
communicate with at least one of the issuer systems 230 
which may or may not be configured to communicate with 
a merchant system 220. The interaction device 290 may 
communicate with the issuer systems 230 using any of 
the aforementioned communication protocols, techniques 
and data links. The communication between the stand 
alone interaction device 290 and the issuer system 230 
may be facilitated by a network 260. In an exemplary em- 
bodiment, the network 260 may be secure against unau- 
thorized eavesdropping. 

[0069] interaction device 290 may provide instructions to the is- 



suer systems 230 for requesting receipt of issuer-owned 
data, such as for example, account data, user member 
identification data, member demographic data, or the like, 
which the issuer wishes to store on the financial transac- 
tion instrument 240. The interaction device 290 may 
communicate with the issuer systems 230 using an issuer 
recognizable communications protocol, language, meth- 
ods of communication and the like, for providing and re- 
ceiving data. In one exemplary embodiment, issuer- 
owned data is received by the interaction device 290 from 
issuer systems 230, and stored onto the financial transac- 
tion instrument 240. The data may be stored or manipu- 
lated in accordance with the issuer provided instructions, 
protocol, storage format, header or trailers received by 
the interaction device from issuer systems 230. The is- 
suer-owned data may be stored on the financial transac- 
tion device 240 in any format recognizable by a merchant 
system 280, and further recognizable by issuer system 
230. In one exemplary embodiment, the issuer owned 
data is stored using a issuer system 230 format which 
may be later formatted in merchant system 280 recogniz- 
able protocol when provided to the merchant system 280. 
In one embodiment, the issuer-owned information is 



stored on the financial transaction instrument 240 in the 
identical format with which it was provided by the issuer 
system 230. In that regard, interaction device 290 may be 
any device configured to receive issuer-owned data from 
an issuer system 230, and write the data to a database, 
such as, for example, a database on instrument 240 or 
database 282. Further, as described more fully below, the 
issuer-owned information may also be provided by the is- 
suer 230 to a remote database 282 where the information 
is stored such that it mirrors the corresponding informa- 
tion stored on the transaction instrument 240. 

[0070] interaction device 290 may be initialized prior to use. For 
example, the interaction device 290 may be any system 
which may be initialized ("configured") to communicate 
with a merchant system 280. Where the interaction device 
is not initialized prior to attempting communications with 
the merchant system 280 or transaction instrument 240, 
the interaction device 280 may be initialized at the mer- 
chant system 280 location. The interaction device may be 
initialized using any conventional method for configuring 
device communication protocol. 

[0071] As noted, in accordance with the invention a transaction 
instrument is provided which permits the storage and 



presentment of at least one of a plurality of data sets for 
completing a transaction. The data sets may be stored on 
the transaction device itself, or on a remote database, as 
described below. The data sets stored with regard to the 
transaction instrument may be modified, deleted, added 
or augmented, as required by the issuer or the user. For 
example, as owner of the data, an issuer may modify a 
data set at the issuer's discretion. The issuer may modify 
the data, data subsets, member identifier and/or applica- 
tions or data sets associated with its transaction account 
program. Such modifications may be completed or sub- 
stantially completed in substantially real-time or at a later 
date, for example, when the transaction instrument is 
next presented. 
[0072] | n a typical example of issuer modification of the data 

sets, one or more data sets may be modified by the issuer 
system 230 directly via the issuer systems 230, upon pre- 
sentment of the financial transaction instrument 240 to 
the system 230. That is, the user 201 may present the 
card to the issuer system 230, and the issuer system 230 
may modify the issuer data stored thereon, using any is- 
suer defined protocol. Alternatively, the modifications, or 
instructions for modification, may be initiated at the is- 



suer system 230, and provided to the network 260. The 
modifications and/or modification instructions may addi- 
tionally be provided to a suitable device configured to 
communicate with the transaction instrument 240, receive 
information regarding the data stored on instrument 240, 
and to write or overwrite the information contained on in- 
strument 240. For example, as noted, interaction device 
290 is a suitable interaction device which may be used to 
provide information to the transaction instrument 240 to 
modify the information stored thereon. Interaction device 
290 may be any device capable of receiving data manage- 
ment instructions from the issuer systems 230 and for 
updating the data stored on the transaction instrument 
240, in accordance with the instructions received. In this 
regard, the interaction device 290 may include any elec- 
tronic components, databases, processors, servers and 
the like which may be used to modify the data stored on 
instrument 240 using any suitable data modification pro- 
tocol as is found in the art. Preferably, the interaction de- 
vice is configured to modify the data on the transaction 
device in accordance with a data owner defined protocol. 
[0073] | n one exemplary embodiment, the interaction device 290, 
may be configured to modify the transaction instrument's 



240 issuer-owned data when the instrument 240 is ini- 
tially configured, prior to providing the instrument 240 to 
the user 201. The interaction device 290 may additionally 
be configured to modify the issuer data on the instrument 
240 when the instrument 240 is next presented, for ex- 
ample, to the stand alone interaction device 290. In this 
regard, the interaction device 290 may receive from mul- 
tiple distinct issuer systems 230, via the network 260, the 
issuer provided modifications/instructions and may up- 
date the instrument 240 in real-time or substantially real- 
time. The modifications may be provided to the interac- 
tion device 290 for storage and later use when the instru- 
ment 240 is next presented. Alternatively, the interaction 
device 290 may be configured to retrieve the instructions 
from the issuer system 230 when the instrument 240 is 
next presented to device 290. Further, where other de- 
vices, such as, for example, a kiosk 270, merchant point 
of interaction device, or the like, are likewise configured 
to modify the issuer data on instrument 240, the inven- 
tion contemplates that the real-time or substantially real- 
time modifications noted above may be made using those 
devices in similar manner as is described with the interac- 
tion device 290. 



[0074] Alternatively, the device to which the transaction instru- 
ment 240 may be presented, may not be equipped for up- 
dating or modifying the data stored on the instrument 
240. For example, merchant system 220 may be any con- 
ventional merchant system which communicates to an is- 
suer system 230, and which permits a user 201 to com- 
plete a financial transaction, but which is not configured 
to modify the issuer data contained on the transaction in- 
strument. In general, conventional merchant systems are 
not configured to write or overwrite data included on the 
payment devices presented to the merchant system for 
processing. That is, the merchant system 220 may include 
little or no additional software to participate in an online 
transaction supported by network 260. Management of 
the data sets on transaction instrument 240 may be per- 
formed independent of the operation of the merchant 
system 220 (e.g., via issuer system 230 or interaction de- 
vice 290). As such, the present invention may require no 
retrofitting of the merchant system 220, to accommodate 
system 200 operation. Thus, where the merchant system 
220 is not configured to modify the data on the transac- 
tion instrument, such modifications may be made as de- 
scribed above with respect to modifications being made at 



the interaction device 290 or by the issuer at the issuer 
230 system. 

[0075] The merchant system 220, kiosk 270, interaction device 
290, may include additional means for permitting the 
transaction instrument user 201 to self-manage the data 
stored on the transaction instrument 240. In this case, the 
systems 220, 270, and 290 may include an additional user 
interface for use by the user 201 to identify the modifica- 
tion action to be taken. Where the systems 220, 270, and 
290 are configured to communicate with the instrument 
240 and to modify the data thereon, the modifications 
may be completed or substantially completed in real-time 
or substantially real-time. For example, the user 201 may 
present the transaction instrument 240 to one of the sys- 
tems 220, 270, or 290, provide instructions to the system 
220, 270, or 290 for modifying the data on instrument 
240. The instructions may include, for example, "ADD," 
"DELETE," "MODIFY," and the system 220, 270, or 290 
may modify the data stored on the instrument 240 in ac- 
cordance therewith. The modifications may be made on 
the instrument in real-time or substantially real-time, for 
example, prior to permitting the instrument 240 to be 
used by the user 201. Alternatively, the modifications or 



instructions for modification may be provided by the user 
201 to the merchant system 220 or kiosk 270, and the 
merchant system 220 or kiosk 270 may further provide 
the modifications/instructions to the network 260 for use 
in later modifying the data. For example, the modifica- 
tions/instructions may be provided by system 220 or 270 
to the issuer system 230 managed by the issuer owning 
the data to be modified. The issuer system 230 may pro- 
vide the modifications to, for example, interaction device 
290, for updating the transaction instrument 240 when 
next presented. The modifications/instructions may addi- 
tionally be provided from the network 260 to a remote 
database, where the issuer-owned data corresponding to 
the transaction device and the issuer may be additionally 
stored (i.e., database 282, described below). In one exem- 
plary embodiment, the modifications/instructions may be 
stored at the issuer system 230, until such time as the 
transaction instrument 240 is next presented to a device 
configured to modify the data on the instrument. Once 
presented, the modifications/instructions may be pro- 
vided to the device (e.g., computer 250, interaction device 
290, etc.) for modifying the instrument 240 data. 
[0076] | n another exemplary embodiment, the user 201 may 



self-manage the data sets by, for example, modifying the 
data sets using a conventional computer system 250, 
which may be in communication with the network 260. 
Computer system 250 may or may not be configured to 
interact with financial transaction instrument 240. Where 
the computer system 250 is not configured to interact 
with the transaction instrument 240, the user 201 may 
provide modifications or instructions to the issuer system 
230 for later use in modifying the corresponding transac- 
tion instrument 240 data, for example, when the instru- 
ment 240 is next presented in similar manner as de- 
scribed above. Where the computer 250 is configured to 
interact with the financial instrument 240 to modify the 
data stored thereon, the user 201 may provide modifica- 
tions/instructions to the computer 250 for modifying the 
data on the financial instrument in real-time or substan- 
tially real-time. That is, the computer 250 may be config- 
ured to interact with, read, add, delete, and/or modify the 
data sets on the instrument 240. Consequently, the com- 
puter 250 may receive modifications/instructions from the 
user 201 and perform the modifications accordingly, and 
may modify the data in real-time or substantially real- 
time. The computer 250 may additionally be configured to 



receive authorization of the modifications/instructions 
from issuer system 230 prior to making the user 201 re- 
quested changes. In one exemplary arrangement, the user 
201 may provide the modifications/instructions via the 
network 260 which may be additionally provided to the is- 
suer system 230. The issuer system 230 may receive the 
user 201 modifications/instructions and verify whether 
the identified updates are available to the user 201 or if 
the identified updates are valid. If the identified updates 
are authorized, the issuer system 230 may update a data 
storage area associated with the transaction instrument 
240. For example, the issuer system 230 may update an 
issuer database (not shown) containing data correspond- 
ing to the issuer-owned data associated with the transac- 
tion instrument 240. Alternatively, the issuer system 230 
may provide modifications/instructions to a database po- 
sitioned remotely to the issuer system 230 for use in 
modifying the data stored thereon, which is associated to 
the transaction instrument 230. As such, in accordance 
with the present invention, a user 201 may self-manage 
the data via, for example, the user computer 250, a kiosk 
270, a merchant system 220, and/or a stand alone inter- 
action device 290. 



[0077] | n one exemplary method of self-management, a user 201 
logs onto a website via user computer 250, or onto a 
stand alone device, such as, for example, interaction de- 
vice 290 or kiosk 270, and selects options for configuring 
data sets on a financial transaction instrument 240. The 
changes may be transmitted to the instrument 240 via a 
instrument reader/writer device 280 configured to com- 
municate the data to instrument 240. In this context, the 
reader/writer device 280 may be any conventional trans- 
action device reader or writer. 

[0078] As noted, modifications to the data stored on the financial 
transaction instrument 240 may be made in real-time or 
substantially real-time when the instrument 240 is pre- 
sented to the interaction device 290, or to a reader/writer 
device 280. However, as noted, various embodiments of 
the invention include a remote database 282 in communi- 
cation with an issuer system 230 via a network 260. The 
remote database 282 may additionally be in communica- 
tion with one of the user computer 250, kiosk 270, mer- 
chant system 220 and/or the interaction device 290, for 
variously receiving modifications or instructions for per- 
forming modifications to the data stored thereon. In addi- 
tion, database 282 may contain a data storage area which 



"mirrors" the data stored on transaction instrument 240. 
In this context "mirrored" or "mirror" may mean that the 
data is stored on database 282 in substantially identical 
configuration and format as stored on the transaction in- 
strument 240. As such, the present invention may be con- 
figured to permit modifications made to instrument 240 
data to be mimicked on corresponding data locations on 
database 282. For example, the user 201 may self- 
manage the data on the database 282 via a user interface 
in communication with the database 282 via the network 
260. In one exemplary embodiment, the user 201 may 
communicate with a "website" which is used to manage 
the database 282, wherein database 282 is a database in- 
cluding unique locations for storing the issuer provided 
data and data sets correlative to the data and data sets 
stored on the transaction instrument 240. The website 
may include an account management application which 
permits the user 201 to select which user accounts to add, 
delete, or modify with respect to the instrument 240. That 
is, the user 201 may provide unique identifying informa- 
tion to the user computer 250 which may be recognized 
by the system (e.g., issuer system 230 or remote system 
managing the database 282) managing database 282, 



thereby permitting the user 201 to access the data corre- 
sponding to the unique identifying information stored on 
database 282. Further, prior to permitting modifications 
to the database 282, the issuer owning the data may re- 
quire authorization that such modifications may be per- 
formed. Further still, the present invention contemplates 
that database 282 may be self-managed by the user 201 
in similar manner, where the merchant system 220, kiosk 
270 and/or interaction device 290 are configured to pro- 
vide modifications/instructions to the issuer systems 230 
and database 282. 
[0079] | n another exemplary embodiment, database 282 serves 
as a temporary or redundant storage space for data sets. 
Thus, a "mirror image" of the data sets currently on the fi- 
nancial transaction instrument 240 may be maintained 
and/or updated at appropriate intervals for facilitating re- 
placement of, for example, a damaged financial transac- 
tion instrument 240. As such, database 282 may be used, 
for example, for verifying the validity or accuracy of the 
information stored on the instrument 240. Also, changes 
to one or more data sets may be stored to database 282 
pending an opportunity to update the financial transaction 
instrument 240. In various embodiments, such updating 



may take place in both directions similar to hot sync tech- 
nology. 

[0080] As noted, in some exemplary embodiments of the inven- 
tion, authorization must be obtained from issuer systems 
230 prior to making any modifications to the data con- 
tained on instrument 240 or database 282. Authorization 
may be obtained by requesting the authorization during 
the modification process. Authorization may be given 
where the user 201 provides the more appropriate secu- 
rity information, which is verified by the issuer system 
230. The security information may be, for example, a se- 
curity code granting access to the issuer-owned data on 
the instrument 240 or database 282. For example, a 
point-of-sale (POS) machine may be configured to allow 
the input of a code, or an answer to a prompt which is 
provided to and verified by issuer system 230. Once veri- 
fied the modification requested may be made to the data 
contained on the financial transaction instrument 240. 

[0081] it should be noted that the authorization code may be 
used to permit the user 201 to select which issuer pro- 
vided data to utilize for completion of a transaction. For 
example, a Point of Interaction Device (POI) device may be 
programmed to search the financial transaction instru- 



ment 240 for a data set containing a particular club mem- 
bership data set, or to locate all available data sets for 
providing to a user 201 display available data sets to the 
user 201, thereby permitting the user 201 to select which 
data set to use to complete a transaction. If no data set is 
found, the POI device may alert the user 201 or prompt 
the merchant to alert the user 201 of the possibility of 
adding issuer-owned data to the financial transaction in- 
strument 240. A positive response to this alert may cause 
the POI device to add an issuer data set to the instrument 
240. 

[0082] it i S noted that the user 201 may already be a member of 
a membership program managed by an issuer system 230 
in which case the associated user 201 membership data 
may be assigned to user 201 for inclusion on instrument 
240. As such, the user 201 may be permitted to add the 
membership data set to the transaction instrument 240. 
Alternatively, the user may become a member by selecting 
to add the membership information to the financial trans- 
action instrument 240, using the interactive device 290. In 
some embodiments, changes made to the data sets stored 
on the transaction instrument 240 may be updated to the 
financial transaction instrument 240 in real-time or sub- 



stantially real-time, where the device 290 is in communi- 
cation with the instrument 240. Or the changes may be 
made the next time the user 201 presents the financial 
transaction instrument 240 to stand alone interaction de- 
vice 290 or to a kiosk 270, merchant system 220, or the 
like. 

[0083] | n another exemplary embodiment of the present inven- 
tion, merchant system 220, kiosk 270, and/or user com- 
puter 250 may be configured to interact with financial 
transaction instrument 240 via a read/write device 280. 
Read/write device 280 may be any device configured to 
communicate with financial transaction 240. In one em- 
bodiment, read/write device 280 is configured to read and 
write to financial transaction instrument 240. For exam- 
ple, read/write device 280 may be a point of interaction 
magnetic card reader/writer. In another example, where 
the transaction instrument 240 includes a RF transmitter/re- 
ceiver for communicating with system 200, read/write de- 
vice 280 may include a mating transponder configured to 
receive and transmit issuer-owned data. Read/write de- 
vice 280 may be configured to select data sets for use by 
a merchant using any suitable selection technique includ- 
ing but not limited to proprietary commands or command 



sequences or use of ISO/IEC 7816-4 application selection 
sequences (e.g., GET command). 

[0084] | n one exemplary embodiment, management of data sets 
is facilitated by annotating the data set with a status indi- 
cator (e.g., condition header); (e.g., LOADED, INITIALIZED, 
READY, BLOCKED, REMOVABLE or DELETED). 

[0085] | n this regard, a data set may have a LOADED status when 
the information related to that data set has been stored in 
association with the financial transaction instrument 240, 
but remains dormant. For example, a credit card account 
may have been added to the financial transaction instru- 
ment 240 that has not yet been activated. In some in- 
stances, the loaded data set needs to be further config- 
ured before it is ready to be used. For example, the data 
set may be modified to include a particular branch in a 
chain of franchise stores, the identification of a user's 201 
primary care physician, or to reflect a users 201 selection 
of a platinum membership status. In another example, a 
loyalty program may be added in association with a finan- 
cial transaction instrument 240, and the data set marked 
LOADED. In another example, the user 201 may interact 
with a kiosk 270 or the like to input personal information 
and configure the loyalty program data set. Once such a 



data set has been configured, it may be annotated with an 
INITIALIZED status. 
[0086] The status of a data set may be set as READY when the 
data set is ready to be utilized. For example, a user 201 
may enter a secret code to indicate that the user 201 is 
ready to use the data set. In one example, the data set 
may be marked as READY when that data set is first ac- 
cessed to perform a transaction. It will be noted that in 
accordance with other embodiments of the present inven- 
tion, the status of a data set may be set at READY the mo- 
ment it is loaded to the financial transaction instrument 
240. Furthermore, it is possible to change the status be- 
tween READY, LOADED, and INITIALIZED, under appropri- 
ate circumstances. Thus, the data sets may be managed 
through any one or more of these states and in various 
orders. 

[0087] ^ mav a | so be desirable to prevent use of a data set and/ 
or the associated functionality for a period of time. Thus, 
the status indicator may be set to BLOCKED. The setting 
of the status indicator to BLOCKED may, for example, dis- 
able the use of the data set. In one exemplary embodi- 
ment, an appropriately configured financial transaction 
instrument reader is configured to recognize the BLOCKED 



status indicator when accessing the data set and to pre- 
vent use of that data set example. 

[0088] | n addition, for various reasons, a user 201 may desire to 
remove a data set from a transaction card 240. The user 
201 may, for example, desire to use the available space 
on the transaction card 240 for other data sets, or may 
remove the data set for security reasons. Furthermore, 
circumstances may arise where the owner of the data set 
desires to remove the data set from one or more transac- 
tion devices 240, such as when a coupon expires. In these 
instances, the data set may be marked as REMOVABLE. 
Under these circumstances, the memory associated with 
the data set is available to receive information associated 
with future added data sets, but for the moment retains 
the old data set. A REMOVABLE data set may again be 
made READY under various configurations. 

[0089] The REMOVABLE data set may subsequently be removed 
from the financial transaction instrument 240 and marked 
DELETED. A DELETED status indicator may be used to indi- 
cate that a portion of the financial transaction instrument 
240 is available to store one or more data sets. It is noted 
that data sets may be directly deleted without going 
through the step of making the data set REMOVABLE. In 



one example, a data set may be removed from the finan- 
cial transaction instrument 240 if the security of the ac- 
count associated with the data set is compromised (e.g., 
stolen password). Furthermore, as appropriate, the status 
of data sets may be changed to different states. Under ap- 
propriate circumstances one or more of any of the six sta- 
tus indicators LOADED, INITIALIZED, READY, BLOCKED, 
REMOVABLE, or DELETED or other suitable status indica- 
tors may be used to annotate a BLOB or other similar data 
set. 

[0090] Although the data sets described herein may be managed 
without status indicators, nevertheless, such status indi- 
cators facilitate management of data. For example, re- 
gardless of a first data set owner's ability to interpret the 
information stored in a data set owned by another party, 
the first owner may interpret the status indicator to deter- 
mine whether the data set is LOADED, DELETED, or the 
like. The determination that a data set is DELETED facili- 
tates the addition of new data sets by independent owners 
without overwriting other data sets on the financial trans- 
action instrument 240. In addition, the use of tags or sta- 
tus indicators may facilitate the use of global rules, which 
may simplify operations and/or commands. Status indica- 



tors may also enhance interoperability between data sets. 
Nevertheless, a data set owner may chose not to use a 
status indicator even if the opportunity is available. 

[0091] Managing of the data sets (step 120) may include one or 
more of the following exemplary steps: add, update, 
modify, replace, verify, delete and/or the like. More par- 
ticularly, FIG. 3 illustrates a general overview of an exem- 
plary data set management method 300 comprising the 
steps of: loading a data set (step 310), initializing a data 
set (step 320), verifying availability of data set (step 330), 
and deleting a data set (step 340). In this manner, a data 
set may be added to a financial transaction instrument 
240 and utilized until it is deleted. The adding and delet- 
ing steps are described in further detail with reference to 
FIG.'s 4 and 5. Furthermore, the ability to update, modify, 
replace and/or delete a data set may be subject to secu- 
rity requirements. 

[0092] | n one embodiment, the various processes may include a 
user 201 facilitating the input of information into a data 
management system to cause the data set to be loaded. 
The information may be inputted via keypad, magnetic 
stripe, smart card, electronic pointer, touchpad and/or the 
like, into a user computer 250, POS terminal, kiosk 270, 



ATM terminal and/or directly into the merchant system 
220 via a similar terminal or computer associated with 
merchant server 222. The information may be transmitted 
via any network 260 discussed herein to merchant system 
220 or issuer systems 230. In another embodiment, the 
merchant may enter the information into an issuer system 
230 on behalf to the user 201. This may occur, for exam- 
ple, when the user 201 and/or issuer system 230 autho- 
rizes the management of data sets on financial transaction 
instrument 240 over a telephone and the service repre- 
sentative inputs the information. In this embodiment, the 
transaction instrument 240 may be updated at the next 
presentment opportunity such as when the user 201 at- 
tempts to compete a transaction using the transaction in- 
strument 240. 

[0093] Any suitable procedures may be utilized to determine 

whether a data set is currently ready for use and available 
(step 330). In one example, when a financial transaction 
instrument 240 is presented, the availability of the data 
set is verified by checking whether the data set has been 
corrupted or blocked (step 332), or deleted (step 333). For 
example, the data set may be checked to determine if the 
data set has been accessed or altered without permission 



("corrupted") or if the data set exists or has been removed 
from the transaction device 240 ("deleted"). The check 
may be performed using any suitable protocol or compar- 
ing data. If the answer to these questions is no, then the 
data set is available and ready for use (step 334). If the 
data is corrupted or blocked, subroutines may be used to 
attempt to retry reading the data (step 336). If the data 
set is marked deleted or removable, subroutines will pre- 
vent access to the data set (step 335) and remove the data 
set (step 340). For example, a suitable subroutine may 
place a DELETE "marker" on the data set which prevents 
the data from being transmitted during completion of a 
transaction. The data set may then be marked for deletion 
and deleted from the transaction device 240 at the next 
presentment of the device. In similar manner, where the 
data set is corrupted, a CORRUPTED marker may be ap- 
pended to the data set and the data set is prevented from 
being transmitted during completion of a transaction. The 
marker may be a header or trailer as discussed herein. 
[0094] various methods may be used to add a data set to a fi- 
nancial transaction instrument 240 or to replace a data set 
on a financial transaction instrument 240. FIG. 4 illus- 
trates an exemplary method of adding a data set to a fi- 



nancial transaction instrument 240, including the general 
steps of presenting the financial transaction instrument 
(step 410), verifying the addition of the data set to the fi- 
nancial transaction instrument (step 420), placing the data 
set in a temporary holding area (step 430), and adding the 
data set (step 440). 
[0095] More particularly, the user 201 presents the financial 

transaction instrument (step 410) to a device 280 config- 
ured to communicate with instrument 240. The user 201 
may present financial transaction instrument 240 at a 
point of purchase or to an interaction device 240 or kiosk 
270. For example, the user 201 may wave the RF transac- 
tion device 240 in front of a POI machine in a retail store, 
which is configured to receive data from the device 240. 
Alternatively, the user 201 may present the financial 
transaction instrument 240 at a self-service location such 
as a kiosk 270 in a mall. Moreover, the user 201 may 
present the financial transaction instrument 240 to a pe- 
ripheral device associated with a personal computer, or 
the like. 

[0096] The user 201 is then given the opportunity to add a data 
set to the transaction instrument 240. For example, device 
280 may detect the absence of a particular data set on the 



transaction instrument by searching the transaction in- 
strument 240 data base and comparing the existing data 
sets to the data set to be added. If the data set to be 
added is not found on the data base, the user 201 may be 
prompted to confirm the addition of this data set to the 
instrument (step 420). The user may be prompted via an 
interactive user interface displaying the option to add the 
data set. In one example, when a user 201 presents a fi- 
nancial transaction instrument 240 to a merchant, the 
card reader detects the absence of a loyalty data set and 
provides a message on a display to the user 201 or the 
store clerk indicating that the loyalty data set can be 
added if desired. The user 201 may answer in the negative 
and complete the purchase using typical transaction 
methods (step 425). Alternatively, if user 201 provides an 
affirmative response, the algorithm may prepare a data 
set for communication with the financial transaction in- 
strument 240 (step 430). The process may determine 
whether the data set (or information that could be used to 
create the data set) exists in some form or on some device 
other than on the financial transaction instrument 240 
(step 432). Determining whether a data set exists may in- 
volve querying an issuer system 230, database 282, or the 



like. For example, the issuer system 230 may compare the 
data set to other data sets the issuer system 230 has as- 
signed to a particular user 201. If the data set is not as- 
signed to a particular user, then issuer system may deter- 
mine that the data set is available for adding to the trans- 
action instrument 240. Determining whether a data set 
exists may also take place when a store clerk verbally asks 
(or a screen prompts) the user 201 to present another 
card containing the information. For example, the data set 
may exist on a movie rental card and stored in magnetic 
stripe form, bar code, and/or the like. 
[0097] |f the data set exists in an accessible form, the data set 
may be captured(step 436). In this example, the user 201 
may present the movie rental card and the data read from 
the movie rental card may then be stored in a data set as- 
sociated with the financial transaction instrument 240. For 
example, the user 201 may desire to add a shopping loy- 
alty card to the user's 201 financial transaction instrument 
240. The user 201 may swipe, scan or otherwise present 
the loyalty card such that the data set from the loyalty 
card is captured. The system may be further configured 
such that the merchant, kiosk 270, or computer system 
may access an issuer system 230 to obtain information for 



creating the data set. Thus, if a user 201 does not have 
the movie rental card on the user's 201 person, the sys- 
tem 230 may prompt the clerk to request identifying/secu- 
rity information and to access the user's 201 account and 
therefore facilitate adding a movie rental data set associ- 
ated with the user's 201 transaction instrument 240. Any 
other suitable methods of capturing data sets may also be 
used. 

[0098] if the data set does not exist, a new data set may be cre- 
ated (step 434) for inclusion on the transaction instrument 
240. Creation of the data set may, for example, involve 
filling out an application, providing name and address, 
creating an account, and/or the like. In either event, the 
pre-existing or newly created data set is temporarily held 
in a storage area (e.g., database 282, local memory or the 
like) for transfer to the transaction instrument 240 (step 
438). Additional data sets may be prepared for transmittal 
to transaction instrument 240 (step 439). 

[0099] | n this exemplary embodiment, the transaction instrument 
240 is presented again to read/write device 280 (step 
442). Read/write device 280 is configured to attempt to 
transfer the data set(s) to the transaction instrument 240 
(step 444). For example, existing read/write device 280 



may be configured with software and/or hardware up- 
grades to transmit data to the transaction instrument 240. 
In one exemplary embodiment, if the data sets were not 
transferred correctly, the process may try the transfer 
again. In another exemplary embodiment, data sets are 
added one at a time or altogether. Thus, a user 201 may 
pass a card through a card reader/writer one or more 
times during the addition process. The transaction may be 
completed (step 425) using the new data set or another 
selected method of payment. The same steps may be used 
in a self-service embodiment, however, in one embodi- 
ment, no financial transaction takes place along with the 
addition of data sets. It should also be noted that under 
appropriate circumstances, a user 201 could add data sets 
at a point of purchase without actually completing a pur- 
chase. 

[0100] | n various exemplary embodiments, the user 201 and/or 
the owner of the data set may manage the data set (i.e., 
steps 432-439) in advance of presenting the transaction 
instrument 240. For example, a user 201 on user com- 
puter 250 may choose to add or delete data sets via a 
website configured for management of data sets. In an- 
other example, an issuer system 230 may add functional- 



ity to an account and may desire to update the data set 
associated with that account. In either example, data sets 
that have been prepared in advance, may be ready for 
transmission upon presentment of the transaction instru- 
ment 240. The transmission of the data sets may be 
transparent to the user 201. For example, the user 201 
may present the transaction instrument 240 (step 442) to 
complete a purchase and the waiting data sets may auto- 
matically be added to the user's 201 card (step 440). 
[° 101 ] Similar steps may be taken to replace or update data sets 
with new information. For example, a user 201 at a point 
of interaction may be informed of an upgrade in function- 
ality associated with an account or other data set. Follow- 
ing similar steps as discussed with reference to FIG. 4, the 
existing data set on the transaction instrument 240 is re- 
placed with a new data set. Moreover, depending on per- 
mission rights and/or hierarchies in place, if any, an ex- 
isting data set may be replaced with an unrelated data set. 
Other methods of adding and replacing data sets may also 
be used to manage data sets on a transaction instrument 
240. 

[0102] Furthermore, data sets may be deleted using any suitable 
techniques. For example, FIG. 5 illustrates an exemplary 



data set deletion method 500. The user 201 presents 
transaction instrument 240 at a point of purchase, self- 
service location, or the like (step 510). The POS device 
may be configured to facilitate the user 201 providing in- 
put regarding deletion of a data set (step 520). For exam- 
ple, the POS device may ask the user 201, via a test 
screen, whether the user 201 desires to manage the data 
sets on the transaction instrument 240. Through a series 
of menus and/or questions, the user 201 may identify 
data sets that the user 201 desires to delete. 
[0103] Furthermore, the POS device may be configured to inter- 
rogate a database 282 or specific issuer systems 230 to 
determine whether the deletion of a data set has been re- 
quested earlier. If the user 201 requests deletion of one or 
more data sets, the data sets are then identified (step 
530). It will be noted that step 530 may occur concur- 
rently with step 520 or the user 201 may request deletion 
of a specific account at this step. In other embodiments, 
accounts may be deleted per predefined rules or policies, 
and/or the like. Upon presenting the transaction instru- 
ment 240 again, the identified data set(s) are removed 
from the transaction instrument 240 (steps 540 and 550). 
Other methods of deleting data sets may also be used to 



manage data sets on a transaction instrument 240. 

[0104] | n an exemplary embodiment, management of the data 
sets may further include selecting preferences for use of 
the data sets. For example, a user 201 may indicate a de- 
sire to use data set A, associated with a low interest rate 
credit card, as a first option, but to use data set B, associ- 
ated with a higher interest rate credit card when data set 
A is not available. In another example, one data set may 
be used for purchases of gas while another data set may 
be used for purchasing travel tickets. The consumer data 
set preferences may be stored on the transaction instru- 
ment 240 as a data set. In this example, when the card is 
presented, all available data sets are read and the card 
reader device determines which data sets are to be used 
based in part on the preferences stored on the card, which 
preferences may be updated from time to time. 

[0105] | n 0 ne exemplary embodiment of the present invention, 
transaction instrument 240 is a RF device configured to 
transmit and receive information via RF frequency. The RF 
instrument 240 may be embodied in any form factor al- 
lowing presentment of the instrument 240 for payment. 
Typical form factors may include a watch, card, FOB, or 
the like. For ease in understanding, the RF transaction in- 



strument may be referred to, herein, as a "FOB." 

[0106] The FOB may be configured to communicate via a radio 
frequency transponder to the merchant systems or ac- 
count systems. In yet another embodiment, the FOB may 
be configured to comprise two or more antennae that are 
both configured to send and receive information and the 
FOB may be responsive to different RF frequencies. In this 
exemplary embodiment, each antenna may be configured 
to communicate using a particular protocol and/or fre- 
quency. Thus, the FOB may be configured to communicate 
with two or more interaction devices 280 that each com- 
municate with the FOB using different transmission fre- 
quencies. For more information on dual antenna FOB's, 
see U.S. Patent Application Serial No. 10/192,488, filed 
July 9, 2002, by inventors Michael J. Berardi, et al., and 
entitled "System and Method for Payment Using Radio 
Frequency Identification in Contact and Contactless 
Transactions" and its progeny, which are hereby incorpo- 
rated by reference. 

[0107] a s noted, the data associated with the transaction instru- 
ment 240 may be modified by the user 201 and/or by the 
issuer system 230. FIG.'s 6 and 7 respectively, depict ex- 
emplary methods for user 201 and issuer system 230 data 



management. For example, with respect to user 201 self- 
management, the issuer system 230 may provide the user 
201 with a transaction instrument 240 (step 602). The in- 
strument 240 may be provided with pre-stored issuer- 
owned data, or the instrument 240 may be configured to 
permit the user 201 to add the data at a later date. The 
user 201 may the present the transaction instrument 240 
to read/write device 280 for initiating the self- 
management process (step 604). The read/write device 
280 may then read the data on the transaction instrument 
240, and provide the data to an interaction device 290 for 
displaying to the user 201 (step 606). Alternatively, the 
interaction device 290 may provide the user 201 a list of 
available data to be added to the instrument 240. 
[0108] The user 201 may then be permitted to identify which 

data the user 201 wishes to modify (step 608). Identifica- 
tion of the data may include providing the data with a 
trailer or header indicating the action to be taken (e.g., 
add, delete, augment, overwrite, etc.). The header and an 
indicator of the data to be modified may then be provided 
to the issuer system 230 (step 610) for verification as to 
whether such desired modifications are available to the 
user 201 (step 612). If the desired modifications are not 



available, the modifications will not be made and the user 
201 is notified accordingly (step 614). The user 201 may 
then be permitted to identify whether other data is to be 
modified (step 616). If so (step 608), the interaction de- 
vice 290 may provide a request for modification to the is- 
suer system 203 (step 610) and the verification process is 
repeated. 

[0109] Alternatively, where the issuer system 230 verifies that the 
modifications may be made (step 612), the interaction de- 
vice 290 may make the modifications to the appropriate 
data on the transaction instrument 240(step 618). Addi- 
tionally, where the system 200 includes a remote 
database 282 for storing a mirror image of the data con- 
tained on transaction instrument 240 (step 620), the in- 
teraction device 290, or issuer system 230, may facilitate 
modification of the remote database 282 (step 622). The 
user 201 may then be permitted to select other data sets 
to modify (step 616), in similar manner as was described 
above. 

[0110] | n either case, where the modifications are complete, the 
user 201 may then present the transaction instrument 
240 to a merchant for use in completing a transaction. 

[0111] FIG. 7 depicts an exemplary method wherein the issuer 



system 230 manages the data contained on the transac- 
tion instrument 240. For example, the issuer may identify 
on the issuer system 230 which data sets are to be modi- 
fied (step 702). The modifications may then be made to 
the corresponding data set stored on the issuer system 
230 (step 706). Where the system 200 includes a remote 
database 282, the issuer system 230 may provide the 
modifications/instructions to the database 282 for updat- 
ing the database 282 accordingly (step 706). 
[° 112 ] In addition, the issuer system 230 may query as to 

whether the issuer system 230 is in possession of the 
transaction instrument 240 for making the modifications 
to the data set on the instrument 240 in real-time or sub- 
stantially real-time (step 708). If so, the modifications are 
made accordingly (step 710) and the instrument 240 may 
then be provided to the user 201 for use in completing a 
transaction using the distinct data sets modified (step 
712). 

[0113] where the issuer system 230 is not in possession of the 
transaction instrument 240 at the time the issuer deter- 
mines that modifications to the data on the instrument 
240 are to be made (step 708), the modifications may be 
made on the issuer system 230 (step 704), and may be 



placed in queue, for uploading to the transaction instru- 
ment 240 when it is next presented to the issuer system 
230 or to an appropriate read/write device 280 (step 
714). When the transaction instrument 240 is presented 
thusly (step 716), the issuer system 230 may be notified 
that the transaction instrument 240 is available for modi- 
fying, and the issuer system 230 may then provide the in- 
structions for modification (e.g., modified data including 
headers) to the appropriate read/write device 280 for 
modifying the transaction instrument 240 (step 718). The 
transaction instrument 240 may then be provided to the 
user 201 for use in completing a transaction (step 712). 
14 ] As noted, the transaction instrument 240 may include 
multiple data sets which correspond to distinct issuer sys- 
tems 230, and which may be used to complete a transac- 
tion. The user 201 may be permitted to choose which data 
set to use for transaction completion. FIG. 8 illustrates an 
exemplary method by which the user 201 may choose 
which of the data sets to use to complete a transaction. 
For example, the user 201 may present the instrument 
240 to a merchant system 220 for use in completing a 
transaction (step 802). The merchant system 220 may 
then read the data stored on the transaction instrument 



240 and report to the user 201 all distinct data sets which 
may be used to complete a transaction (804). The user 
201 may then select the appropriate data set (step 806) 
and the transaction is completed accordingly (step 808). 

[° 115 ] It should be noted that completion of a transaction may 
be performed under any business as usual standard em- 
ployed by the merchant and/or issuer system 230. For 
example, the merchant server 222 may be configured to 
communicate transaction data to the appropriate issuer 
system 230, in real-time or substantially real-time, or by 
using batch processing at the end of each day. Any suit- 
able means for delivering the transaction data to the is- 
suer systems 230 may be used. In one exemplary embod- 
iment of the present invention, the transaction data may 
be delivered to the issuer system 230 via a network 260. 
The issuer system 230 may receive the transaction infor- 
mation and process the transaction under issuer defined 
protocol independent of any other protocol used by other 
issuers to process a transaction. The issuer system 230 
may receive the transaction data and provide the mer- 
chant with the appropriate satisfaction for the transaction. 

[° 116 ] It should be appreciated that the particular implementa- 
tions shown and described herein are illustrative of the 



invention and its best mode and are not intended to oth- 
erwise limit the scope of the present invention in anyway. 
Indeed, for the sake of brevity, conventional data net- 
working, application development and other functional 
aspects of the systems (and components of the individual 
operating components of the systems) may not be de- 
scribed in detail herein. It should be noted that many al- 
ternative or additional functional relationships or physical 
connections may be present in a practical data set man- 
agement system. 
1? ] As may be appreciated by one of ordinary skill in the art, 
the present invention may be embodied as a method, a 
data processing system, a device for data processing, 
and/or a computer program product. Accordingly, the 
present invention may take the form of an entirely soft- 
ware embodiment, an entirely hardware embodiment, or 
an embodiment combining aspects of both software and 
hardware. Furthermore, the present invention may take 
the form of a computer program product on a computer- 
readable storage medium having computer-readable pro- 
gram code means embodied in the storage medium. Any 
suitable computer-readable storage medium may be uti- 
lized, including hard disks, CD-ROM, optical storage de- 



vices, magnetic storage devices, and/or the like. 

[0118] These computer program instructions may also be stored 
in a computer-readable memory that can direct a com- 
puter or other programmable data processing apparatus 
to function in a particular manner, such that the instruc- 
tions stored in the computer-readable memory produce 
an article of manufacture including instruction means 
which implement the function specified in the flowchart 
block or blocks. The computer program instructions may 
also be loaded onto a computer or other programmable 
data processing apparatus to cause a series of operational 
steps to be performed on the computer or other pro- 
grammable apparatus to produce a computer-imple- 
mented process such that the instructions which execute 
on the computer or other programmable apparatus in- 
clude steps for implementing the functions specified in 
the flowchart block or blocks. 

[° 119 ] It should be noted that although the present invention is 
discussed with respect to Internet Service Providers, and 
systems and networks which may communicate via a 
leased line (Tl, D3, TCP/IP etc.), the invention is not so 
limited. The present invention contemplates conventional 
protocol, networks and systems which support a wide 



range of data transfer. For example, in accordance with 
this invention, a transaction may be completed using tele- 
phone lines connecting long distance carrier systems. In 
this instance, the issuer-owned data which may be in- 
cluded on transaction instrument 240 using any of the 
methods discussed herein, may be an account number 
which corresponds to long distance calling time such as 
may be done with a conventional calling card. 
[0120] where the transaction instrument 240 is loaded with sev- 
eral distinct data sets, each corresponding to a distinct 
data set owner operating on distinct and non-compatible 
communications network, the user of the transaction in- 
strument 240 may use the instrument to complete long 
distance calls on each of the distinct communications net- 
work, independently of the other. This is especially useful 
for a transaction instrument 240 user who may travel to 
different locations, where the different locations support 
different long distance communications network. In this 
exemplary embodiment, the present invention enables a 
user to anticipate which communications network is avail- 
able in many different travel destinations, and include the 
corresponding mating data set on transaction instrument 
240 prior to beginning travel. In this way, the transaction 



instrument 240 user may be prepared to use the transac- 
tion instrument 240 as a long distance calling card irre- 
spective of his anticipated travel destination. 
[° 121 ] In the foregoing specification, the invention has been de- 
scribed with reference to specific embodiments. However, 
it may be appreciated that various modifications and 
changes can be made without departing from the scope of 
the present invention. For example, the issuer may reserve 
all management of data stored on the transaction instru- 
ment, thereby prohibiting the user from modifying the is- 
suer owned data thereon. Further, each issuer system may 
have its own data management protocol, which necessar- 
ily does not interfere with or depend upon the data man- 
agement protocol of other issuer systems. As such, the 
specification and figures are to be regarded in an illustra- 
tive manner applicable irrespective of the data processing 
protocol used by a data set owner, rather than a restrictive 
one, and all such modifications are intended to be in- 
cluded within the scope of present invention. Accordingly, 
the scope of the invention should be determined by the 
appended claims and their legal equivalents, rather than 
by the examples given above. For example, the steps re- 
cited in any of the method or process claims may be exe- 



cuted in any order and are not limited to the order pre- 
sented. 

[0122] Benefits, other advantages, and solutions to problems 
have been described above with regard to specific em- 
bodiments. However, the benefits, advantages, solutions 
to problems, and any element(s) that may cause any ben- 
efit, advantage, or solution to occur or become more pro- 
nounced are not to be construed as critical, required, or 
essential features or elements of any or all the claims. As 
used herein, the terms "comprises," "comprising," or any 
other variation thereof, are intended to cover a non- 
exclusive inclusion, such that a process, method, article, 
or apparatus that comprises a list of elements does not 
include only those elements but may include other ele- 
ments not expressly listed or inherent to such process, 
method, article, or apparatus. Further, no element de- 
scribed herein is required for the practice of the invention 
unless expressly described as "essential" or "critical." 



